The present invention relates generally to database systems, and more particularly to a method of monitoring changes in values of attributes of objects in object-oriented database systems.
In an object-oriented database system, an "object" is a kind of entity. An object has certain "attributes", or characteristics, associated with it. A "view" of an object is a set of some of the attributes associated with that object. To "materialize" a certain view respecting a given object means to provide the values of those attributes which make up that view.
Some attributes have values which are stored in the database; these attributes are accessed by retrieving them from storage. An "extensional" function is a procedure which is used for retrieving such values from storage. Other attributes have values which are not stored but rather are derived (by computation or the like) as needed; an "intensional" function is a procedure which is used for deriving such values (and which has no undesired side effects).
For example, an employer might have a database system for keeping certain information about its employees. Each employee would be known to the database system as an "object" of type EMPLOYEE. The database might include values for each of the following attributes of an EMPLOYEE object:
NAME PA1 DATE OF BIRTH PA1 HOME ADDRESS PA1 MONTHLY SALARY PA1 HIRE DATE
(In addition, the system gives each employee a unique identifier so that two employees having the same name can easily be distinguished.)
As already noted, some attributes can be derived from others. For example, every employee has an AGE, but if the system knows an employee's birthdate it can easily compute that employee's age. Therefore, to save space and to preserve system integrity only the value of the employee's birthdate is stored in the database; the employee's age is computed whenever it is needed.
An employee named Bill Johnson might be represented by the following attribute values in the database:
______________________________________ NAME: Bill Johnson BIRTH DATE: 4-5-60 HOME ADDRESS: 123 Main Street, Palo Alto, CA 94303 MONTHLY SALARY: $2,500.00 HIRE DATE: 11-20-85 ______________________________________
One "view" of an employee might consist only of the employee's name and address. Such a view might be used, for example, to have the computer print an envelope in which a notice to employees would be mailed. To "materialize" this view for a given employee it would be necessary to call two extensional functions--"Name" and "Address"--which would return the values of the attributes NAME and ADDRESS of the designated employee.
Another view of an employee might consist of the employee's name, age, monthly salary and number of years with the company. This view might be used, for example, to calculate how much to credit to the employee's retirement account. To materialize this view it would be necessary to call two extensional functions--"Name" and "Monthly Salary"--and two intensional functions--"Age" and "Number of Years with Company." The two intensional functions would return the required values of the attributes AGE and NUMBER OF YEARS WITH COMPANY by performing computations on other values returned by extensional or other intensional functions and which ultimately are derived from values which are stored in the database.
A typical computer system includes a central processing unit, a main memory, storage media such as magnetic disks, a terminal which includes for example a keyboard and a monitor screen, and a plurality of workstations. Each workstation comprises a terminal and usually a local processing unit and memory as well. Users at the various workstations use the computer to perform a variety of tasks.
A "client" of a database system is an applications program which interacts with the database system. Such a client program may be executed by the central processor or by a local processing unit in a workstation. A user may be running a plurality of client programs simultaneously.
Occasions may arise when a client needs to be alerted if certain values in the database are changed. In the example of the employee database discussed above, at one workstation a client program might be updating the database with respect to various financial matters, including the amount to deposit in each employee's retirement account for the previous month, while at a different workstation (possibly hundreds of miles away) another client program might be updating the database by posting all the salary raises which were granted during that month. The first client program must be alerted if anything done by either program results in changes in the values of financial data respecting one of the employees on whose retirement account the first client is then working.
More generally, a notification that a monitored value has changed may be needed for any of a number of purposes. A client may wish to be alerted if an abnormal condition occurs. The occurrence of a certain condition or set of conditions may be a signal to start running a certain application program. A graphic display may need to be updated whenever there is a change in a parameter being displayed. A client may need to recompute certain other values which depend on the value which has just changed (as in the above example of the employee retirement account).
Monitoring imposes a heavy computational and input/output overhead on a database system, especially if the system is large and a number of values are being monitored at the same time for several different clients. Various methods have been proposed to minimize this overhead. For example, in one such system an "alerter" is called if specified boolean conditions are satisfied (O. P. Buneman and E. K. Clemons, "Efficiently Monitoring Relational Databases," ACM Transactions on Database Systems 4, 3, September 1979, pp 368-382). A "retrieve always" mechanism in another system causes queries to be re-executed upon each update to specified relations (M. Stonebraker, "Triggers and Inference in Database Systems," in M. Brodie and J. Mylopoulos (eds.), On Knowledge Based Management Systems, Springer-Verlag, 1986).
Systems of "triggers" have been proposed for relational database systems; such triggers typically invoke a database procedure upon updates of user-specified base relations (see, for example, M. Astrahan et al., "System R: A Relational Approach to Database Management," ACM TRansactions on Database Systems, 1 (2), June 1976).
A technique which is somewhat similar to the trigger system is the use of a "declarative integrity constraint," in which a proffered update to the database is rejected if specified boolean conditions are not satisfied at commit time (see, for example, M. Stonebraker, "Implementation of Integrity Constraints and Views by Query Modification," Proc. ACM SIGMOD Conf., San Jose, Calif., May 1975).
Another technique, access-oriented programming, is implemented in some object-oriented languages such as "LOOPS". A message to set values of instance variables is intercepted by means of a user-provided trigger procedure which may in turn set or display some other value (M. J. Stefik et al., "Integrating Access-Oriented Programming Into a Multiparadigm Environment," IEEE Software 3, 10, January 1986, pp. 10-18). The trigger procedures are dynamically added and removed from running systems to avoid interfering with other system logic (K. Osterbye, "Active Objects: An Access Oriented Framework for Object-Oriented Languages," Journal of Object-Oriented Programming, Vol. 1, No. 2, June/July 1988, pp. 6-10).
Finally, expert systems such as "SYNTEL" and "OPS5" provide a method of monitoring virtual memory data retrieved from persistent data (R. Reboh and T. Risch, "Syntel: Knowledge Programming Using Functional Representations," Proc. AAAI-86, Philadelphia, Pa., August 1986, pub. Morgan Kaufman, Los Altos, Calif., 1986, pp. 1003-1007).
Each of these proposed methods offers certain benefits, primarily in the context of the particular environment for which it was designed. However, there remains a need for an efficient way to monitor objects in an object-oriented database system which interacts cooperatively with client programs.